home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / The World of Computer Software.iso / jpegfaq.txt < prev    next >
Text File  |  1993-01-05  |  36KB  |  648 lines
  1. =========================================================================
  2. Xref: news.acns.nwu.edu comp.graphics:14833 alt.binaries.pictures.d:4783 alt.graphics.pixutils:3323 alt.binaries.pictures.erotica.d:5445 news.answers:1966
  3. Path: uicvm.uic.edu!news.acns.nwu.edu!zaphod.mps.ohio-state.edu!
  4.  uakari.primate.wisc.edu!ames!agate!stanford.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!tgl
  5. From: tgl+@cs.cmu.edu (Tom Lane)
  6. Newsgroups: comp.graphics,alt.binaries.pictures.d,alt.graphics.pixutils,alt.binaries.pictures.erotica.d,news.answers
  7. Subject: JPEG image compression: Frequently Asked Questions
  8. Summary: Useful info about JPEG (JPG) image files and programs
  9. Keywords: JPEG, image compression, FAQ
  10. Message-ID: <faq_709834264@g.gp.cs.cmu.edu>
  11. Date: 29 Jun 92 16:11:15 GMT
  12. Expires: Mon, 27 Jul 92 16:11:04 GMT
  13. Reply-To: jpeg-info@uunet.uu.net
  14. Followup-To: alt.binaries.pictures.d
  15. Organization: School of Computer Science, Carnegie Mellon
  16. Lines: 626
  17. Approved: news-answers-request@MIT.Edu
  18. Supersedes: <faq_708647975@g.gp.cs.cmu.edu>
  19. Nntp-Posting-Host: g.gp.cs.cmu.edu
  20. Originator: tgl@G.GP.CS.CMU.EDU
  21.  
  22. Archive-name: jpeg-faq
  23. Last-modified: 29 June 1992
  24.  
  25. This FAQ article discusses JPEG image compression.  Suggestions for
  26. additions and clarifications are welcome.
  27.  
  28. This article includes the following sections:
  29.  
  30. 1)  What is JPEG?
  31. 2)  Why use JPEG?
  32. 3)  How well does it work?
  33. 4)  What are good "quality" settings for JPEG?
  34. 5)  When should I use JPEG, and when should I stick with GIF?
  35. 6)  Where can I get JPEG software?
  36.     6A) "canned" software, viewers, etc.
  37.     6B) source code
  38. 7)  What's all this hoopla about color quantization?
  39. 8)  How does JPEG work?
  40. 9)  What about lossless JPEG?
  41. 10)  Why all the argument about file formats?
  42. 11)  And what about arithmetic coding?
  43. 12)  Does loss accumulate with repeated compression/decompression?
  44.  
  45. ----------
  46.  
  47.  
  48. 1)  What is JPEG?
  49.  
  50. JPEG (pronounced "jay-peg") is a standardized image compression mechanism.
  51. JPEG stands for Joint Photographic Experts Group, the original name of the
  52. committee that wrote the standard.  JPEG is designed for compressing either
  53. full-color or gray-scale digital images of "natural", real-world scenes.
  54. It does not work as well on non-realistic images, such as cartoons or line
  55. drawings.
  56.  
  57. JPEG does not handle black-and-white (1-bit-per-pixel) images, nor does it
  58. handle motion picture compression.  Standards for compressing those types
  59. of images are being worked on by other committees, named JBIG and MPEG
  60. respectively.
  61.  
  62. JPEG is "lossy", meaning that the image you get out of decompression isn't
  63. quite identical to what you originally put in.  The algorithm achieves much
  64. of its compression by exploiting known limitations of the human eye, notably
  65. the fact that small color details aren't perceived as well as small details
  66. of light-and-dark.  Thus, JPEG is intended for compressing images that will
  67. be looked at by humans.  If you plan to machine-analyze your images, the
  68. small errors introduced by JPEG may be a problem for you, even if they are
  69. invisible to the eye.
  70.  
  71. A useful property of JPEG is that the degree of lossiness can be varied by
  72. adjusting compression parameters.  This means that the image maker can trade
  73. off file size against output image quality.  You can make *extremely* small
  74. files if you don't mind poor quality; this is useful for indexing image
  75. archives, making thumbnail views or icons, etc. etc.  Conversely, if you
  76. aren't happy with the output quality at the default compression setting, you
  77. can jack up the quality until you are satisfied, and accept lesser compression.
  78.  
  79.  
  80. 2)  Why use JPEG?
  81.  
  82. There are two good reasons: to make your image files smaller, and to store
  83. 24-bit-per-pixel color data instead of 8-bit-per-pixel data.
  84.  
  85. Making image files smaller is a big win for transmitting files across
  86. networks and for archiving libraries of images.  Being able to compress a
  87. 2 Mbyte full-color file down to 100 Kbytes or so makes a big difference in
  88. disk space and transmission time!  (If you are comparing GIF and JPEG, the
  89. size ratio is more like four to one.  More details below.)
  90.  
  91. Unless your viewing software supports JPEG directly, you'll have to convert
  92. JPEG to some other format for viewing or manipulating images.  Even with a
  93. JPEG-capable viewer, it takes longer to decode and view a JPEG image than to
  94. view an image of a simpler format (GIF, for instance).  Thus, using JPEG is
  95. essentially a time/space tradeoff: you give up some time in order to store
  96. or transmit an image more cheaply.
  97.  
  98. It's worth noting that when network or phone transmission is involved, the
  99. time savings from transferring a shorter file can be much greater than the
  100. extra time to decompress the file.  I'll let you do the arithmetic yourself.
  101.  
  102. The other reason why JPEG will gradually replace GIF as the standard Usenet
  103. posting format is that JPEG can store full color information: 24 bits/pixel
  104. (16 million colors) instead of 8 or less (256 or fewer colors).  If you have
  105. only 8-bit display hardware then this may not seem like much of an advantage
  106. to you.  Within a couple of years, though, 8-bit GIF will look as obsolete as
  107. black-and-white MacPaint format does today.  Furthermore, for reasons detailed
  108. in section 7, JPEG is far more useful than GIF for exchanging images among
  109. people with widely varying color display hardware.  Hence JPEG is considerably
  110. more appropriate than GIF for use as a Usenet posting standard.
  111.  
  112.  
  113. 3)  How well does it work?
  114.  
  115. Pretty darn well.  Here are some sample file sizes for an image I have handy,
  116. a 727x525 full-color image of a ship in a harbor.  The first three files are
  117. for comparison purposes; the rest were created with the free JPEG software
  118. described in section 6B.
  119.  
  120. File       Size in bytes                Comments
  121.  
  122. ship.ppm        1145040  Original file in PPM format (no compression;
  123.                          3 bytes per pixel plus a few bytes overhead)
  124. ship.ppm.Z       963829  PPM file passed through Unix compress
  125.                          compress doesn't accomplish a lot, you'll note.
  126. ship.gif         240438  Converted to GIF with ppmquant -fs 256 | ppmtogif
  127.                          Most of the savings is the result of losing color
  128.                          info: GIF saves 8 bits/pixel, not 24.  (See sec. 7.)
  129.  
  130. ship.jpg95       155622  cjpeg -Q 95    (highest useful quality setting)
  131.                          This is indistinguishable from the 24-bit original,
  132.                          at least to my nonprofessional eyeballs.
  133. ship.jpg75        58009  cjpeg -Q 75    (default setting)
  134.                          You have to look mighty darn close to distinguish this
  135.                          from the original, even with both on-screen at once.
  136. ship.jpg50        38406  cjpeg -Q 50
  137.                          This has slight defects; if you know what to look
  138.                          for, you could tell it's been JPEGed without seeing
  139.                          the original.  Still as good image quality as many
  140.                          recent postings in Usenet pictures groups.
  141. ship.jpg25        25192  cjpeg -Q 25
  142.                          JPEG's characteristic "blockiness" becomes apparent
  143.                          at this setting (djpeg -b helps some).  Still, I've
  144.                          seen plenty of Usenet postings that were of poorer
  145.                          image quality than this.
  146. ship.jpg5o         6587  cjpeg -Q 5 -o  (-o reduces table overhead)
  147.                          Blocky, but perfectly satisfactory for preview or
  148.                          indexing purposes.  Note that this file is TINY:
  149.                          the compression ratio from the original is 173:1 !
  150.  
  151. In this case JPEG can make a file that's a factor of four or five smaller
  152. than a GIF of comparable quality (the -Q 75 file is every bit as good as the
  153. GIF, better if you have a full-color display).  This seems to be a typical
  154. ratio for real-world scenes.
  155.  
  156.  
  157. 4)  What are good "quality" settings for JPEG?
  158.  
  159. (Note: the -Q settings discussed in this article apply to the free JPEG
  160. software described in section 6B.  Other JPEG implementations, such as Image
  161. Alchemy, may use a completely different quality scale.)
  162.  
  163. The name of the game in using JPEG is to pick the lowest quality setting
  164. (smallest file size) that decompresses into an image indistinguishable from
  165. the original.  This setting will vary from one image to another and from one
  166. observer to another, but here are some rules of thumb.
  167.  
  168. The default quality setting (-Q 75) is very often the best choice.  This
  169. setting is about the lowest you can go without expecting to see defects in a
  170. typical image.  Try -Q 75 first; if you see defects, then go up.  Except for
  171. experimental purposes, never go above -Q 95; saying -Q 100 will produce a
  172. file two or three times as large as -Q 95, but of hardly any better quality.
  173.  
  174. If the image was less than perfect quality to begin with, you might be able to
  175. go down to -Q 50 without objectionable degradation.  On the other hand, you
  176. might need to go to a HIGHER quality setting to avoid further degradation.
  177. The second case seems to apply most of the time when converting GIFs to JPEG.
  178. The default -Q 75 is about right for compressing 24-bit images, but -Q 85 to
  179. 95 is usually better for converting GIFs (see next section for more info).
  180.  
  181. If you want a very small file (say for preview or indexing purposes) and are
  182. prepared to tolerate large defects, a -Q setting in the range of 5 to 10 is
  183. about right.  -Q 2 or so may be amusing as "op art".
  184.  
  185. Another recommendation: when you are making a final version of an image for
  186. posting on Usenet or archiving, specify "-o" to cjpeg.  This will make the
  187. file a little smaller without affecting image quality; it will take longer
  188. to do the compression, but not any longer to decompress.
  189.  
  190.  
  191. 5)  When should I use JPEG, and when should I stick with GIF?
  192.  
  193. As a rule of thumb, JPEG is superior to GIF for storing full-color or
  194. gray-scale images of "realistic" scenes; that means scanned photographs and
  195. similar material.  JPEG is superior even if you don't have 24-bit display
  196. hardware, and it is a LOT superior if you do.  (See section 7 for details.)
  197.  
  198. GIF does significantly better on images with only a few distinct colors,
  199. such as cartoons and line drawings.  In particular, large areas of pixels
  200. that are all *exactly* the same color are compressed very efficiently indeed
  201. by GIF.  JPEG can't squeeze these files as much as GIF does without
  202. introducing visible defects.  This sort of image is best kept in GIF form.
  203. (Incidentally, many people have developed an odd habit of putting a large
  204. constant-color border around a GIF image.  This was nearly free in terms of
  205. storage cost in GIF files.  It is NOT free in JPEG files.  Do yourself a
  206. favor and don't add a border; let your viewer blank out unused screen area.
  207. If you're converting a GIF to JPEG, crop off any border first.)
  208.  
  209. JPEG also has a hard time with very sharp edges: a row of pure-black pixels
  210. adjacent to a row of pure-white pixels, for example.  Sharp edges tend to
  211. come out blurred unless you use a very high quality setting.  Again, this
  212. sort of thing is not found in scanned photographs, but it shows up fairly
  213. often in GIF files: borders, overlaid text, etc.  The blurriness is
  214. particularly objectionable with text that's only a few pixels high.
  215. If you have a GIF with a lot of small-size overlaid text, don't JPEG it.
  216.  
  217. Computer-drawn images (ray-traced scenes, for instance) usually fall between
  218. scanned images and cartoons in terms of complexity.  The more complex and
  219. subtly rendered the image, the more likely that JPEG will do well on it.
  220.  
  221. If you have an existing library of GIF images, you may wonder whether you
  222. should convert them to JPEG.  You will lose some image quality if you do.
  223. (Section 7, which argues that JPEG image quality is superior to GIF, only
  224. applies if both formats start from a full-color original.  If you start from
  225. a GIF, you've already irretrievably lost a great deal of information; JPEG
  226. can only make things worse.)  However, the disk space savings may justify
  227. converting anyway.  This is a decision you'll have to make for yourself.
  228. If you do convert a GIF library to JPEG, I recommend looking at each JPEG
  229. to make sure you are happy with it before throwing away the corresponding
  230. GIF; that will give you a chance to re-do the conversion with a higher
  231. quality setting if necessary.
  232.  
  233. Experience to date suggests that large, high-quality GIFs are the best
  234. candidates for conversion to JPEG.  They chew up the most storage so offer
  235. the most potential savings, and they convert to JPEG with least degradation.
  236. Don't waste your time converting any GIF much under 100 Kbytes.  Also, don't
  237. expect JPEG files converted from GIFs to be as small as those created
  238. directly from full-color originals.  To maintain image quality you may have
  239. to let the converted files be as much as twice as big as straight-through
  240. JPEG files would be (i.e., shoot for 1/2 or 1/3rd the size of the GIF file,
  241. not 1/4th as shown in the earlier comparisons).  A -Q setting of 85 to 95
  242. will minimize the additional degradation caused by converting a GIF to JPEG.
  243.  
  244.  
  245. 6)  Where can I get JPEG software?
  246.  
  247. 6A) If you are looking for "canned" software, viewers, etc:
  248.  
  249. The first part of this list is system-specific programs that only run on one
  250. kind of system.  If you don't see what you want for your machine, check out
  251. the portable JPEG software described at the end of the list.
  252.  
  253. X Windows:
  254.  
  255. John Bradley's free XV (version 2.00 and up) is an excellent viewer for JPEG,
  256. GIF, and other image formats.  It's available for FTP from export.lcs.mit.edu
  257. or ftp.cis.upenn.edu.  The file is called 'xv-???.tar.Z' (where ??? is the
  258. version number, currently 2.21) and is located in the 'contrib' directory on
  259. export or the 'pub/xv' directory at upenn.  XV reduces all images to 8 bits
  260. internally, which means it's not a real good choice if you have a 24-bit
  261. display (you still get only 8-bit color).  Also, you shouldn't use XV to
  262. convert full-color images to JPEG, because they'll get color-quantized first.
  263.  
  264. "xloadimage" is less featureful than XV, but it will do the right thing on
  265. 24-bit displays.  xloadimage is free and available from export.lcs.mit.edu,
  266. file contrib/xloadimage.3.01.tar.Z.  Version 3.01 does not read JPEG files,
  267. but it will read the PPM files put out by the free JPEG software described in
  268. 6B.  There is also a patched version called "xli" (see files xli.* in same
  269. directory) that does read JPEG directly.  However, xli is a quick hack rather
  270. than an official release; caveat user.
  271.  
  272. Another good choice for X Windows is John Cristy's free ImageMagick package,
  273. also available from export, file contrib/ImageMagick.tar.Z.  The viewer
  274. included in this package handles 24-bit displays correctly; for colormapped
  275. displays, it does better (though slower) color quantization than XV or the
  276. basic free JPEG software.
  277.  
  278. MS-DOS:
  279.  
  280. Currently there is only one usable JPEG viewer for plain MS-DOS (non-Windows);
  281. that's Eric Praetzel's free DVPEG.  The current version, 1d, is available by
  282. FTP from sunee.waterloo.edu, file pub/jpeg/viewers/dvpeg1d.zip.  This is a
  283. prototype with a rather unpolished user interface, and it only supports
  284. the most common super-VGA display cards, but hey, it's free.
  285.  
  286. If DVPEG doesn't work on your hardware, you'll need to use one of the
  287. following conversion programs to convert JPEG to GIF, then view with your
  288. favorite GIF viewer.
  289.  
  290. The Independent JPEG Group's free JPEG converters are FTPable from
  291. wuarchive.wustl.edu (128.252.135.4), directory mirrors/msdos/graphics, file
  292. jpeg3.zip (or jpeg3386.zip if you have a 386 and extended memory); also from
  293. SIMTEL20 and its other mirror sites.  The same files were posted to
  294. comp.binaries.ibm.pc (volume 18, issues 123-130) and should be available
  295. from any c.b.i.p archive site.  These files are DOS compilations of the free
  296. source code described in section 6B.
  297.  
  298. Handmade Software offers two rather pricy shareware programs: Image Alchemy
  299. and GIF2JPG/JPG2GIF (contact hsi@netcom.com for details).  The PC versions of
  300. these programs are available for FTP from wuarchive.wustl.edu, directory
  301. mirrors/msdos/graphics, files alchmy15.zip and gif2jpg5.zip; also from
  302. SIMTEL20 and its other mirror sites.  GIF2JPG/JPG2GIF only perform JPEG<=>GIF
  303. format conversion.  Image Alchemy converts files between these and many other
  304. formats, and can also display images on some types of hardware.  The display
  305. option is limited and not very high quality, so you'll still want a separate
  306. viewer program.  (CAUTION: GIF2JPG produces a proprietary file format unless
  307. you specify -j.  Be sure to use -j if you want to exchange JPEG files with
  308. other Usenet users.  For that matter, it's not real clear that you should be
  309. posting JPEG files made from GIFs; see section 5.)
  310.  
  311. In my biased opinion, the free JPEG software is a better choice than
  312. GIF2JPG/JPG2GIF; it's faster, as good or better image quality, and free :-).
  313. On the other hand, Image Alchemy may be worth its price, if you need the
  314. additional conversion and image manipulation capabilities it provides.
  315.  
  316. Microsoft Windows:
  317.  
  318. There are a couple of shareware JPEG viewers available by FTP.  Look for
  319. WinJPEG (current version is 1.1, available from wuarchive.wustl.edu:
  320. mirrors/msdos/windows3/winjp110.zip; also at SIMTEL20 or any of its mirror
  321. sites) or ColorView (current version is 0.97, wuarchive.wustl.edu:
  322. mirrors/win3/desktop/cview097.zip).  WinJPEG seems to be a shade faster and
  323. more robust than the current prototype version of ColorView, but they have
  324. different features so you may want to try both.
  325.  
  326. At least two freeware Windows JPEG viewers are also undergoing beta test and
  327. should be out shortly; watch this space...
  328.  
  329. The DOS conversion programs described above can be used inside a Windows
  330. DOS window.
  331.  
  332. Macintosh:
  333.  
  334. Apple has released a free program called PictPixie (formerly known as
  335. PictCompressor) that can convert the Usenet-standard JFIF JPEG format to and
  336. from QuickTime's internal JPEG format.  PictPixie can also be used as a
  337. viewer for JFIF, QuickTime JPEG, and GIF files.  You can get PictPixie from
  338. ftp.apple.com, file dts/mac/quicktime/pictpixie.hqx.  You need both
  339. QuickTime and 32-bit QuickDraw to run PictPixie (and therefore you must be
  340. running System 6.0.7 or later).  You can get QuickTime from the same FTP
  341. directory; I think 32-bit QuickDraw is an optional item on the System 6.0.7
  342. disks.  PictPixie is considered a developer's tool; you may not care for its
  343. user interface.  There is a simplified version of this program in the
  344. QuickTime Starter Kit.
  345.  
  346. Another good choice is JPEGView, a free program for viewing both JFIF and
  347. QuickTime JPEG files, as well as converting between the two formats.
  348. The current version, 1.0, is much improved over the initial release (0.9).
  349. Get it from sumex-aim.stanford.edu, file /info-mac/app/jpeg-view-10.hqx.
  350. This program requires System 7 and QuickTime.  It doesn't do quite as much
  351. as PictPixie, but it is fast and handier than PictPixie for skimming through
  352. lots of images.
  353.  
  354. Storm Technology has released a free JPEG viewer called Picture Decompress.
  355. This is generally inferior to PictPixie or JPEGView, but it will run without
  356. System 7 or QuickTime, so you may be forced to use it on older systems.
  357. You'll still need 32-bit QuickDraw, though.  This program can be FTPed from
  358. sumex-aim.stanford.edu, file /info-mac/app/picture-decompress-201.hqx.  Make
  359. sure you get version 2.0.1 or later; earlier versions are not compatible
  360. with JFIF file format.  You'll also need a tool for adjusting file type
  361. codes; you must set the type of a downloaded image file to 'JPEG' to allow
  362. Picture Decompress to open it.
  363.  
  364. On 8-bit-color Macs, neither Picture Decompress nor JPEGView produce really
  365. high quality displays, since they do quick-and-dirty color reduction (this
  366. is not a problem if you are fortunate enough to have a 24-bit display).
  367. I hear that PictPixie does better than the other two programs.  (The free
  368. JPEG software, described later, does an even better job of reducing JPEG
  369. images to 8-bit color.  Unfortunately, no one has gotten around to releasing
  370. a precompiled version of the free software for Macintoshes.)
  371.  
  372. Amiga:
  373.  
  374. I'm told the shareware program HAMLab is about the best tool for viewing/
  375. converting JPEG files.  This should be available from most big Amiga archive
  376. sites.
  377.  
  378. Portable software for almost any system:
  379.  
  380. If none of the above fits your situation, you can obtain and compile the free
  381. JPEG conversion software described in 6B.  You'll also need a viewer program.
  382. If your display is 8 bits or less, any GIF viewer will do fine; if you have a
  383. display with more color capability, try to find a viewer that can read Targa
  384. or PPM 24-bit image files.
  385.  
  386. If you are not reasonably handy at configuring and installing portable C
  387. programs, you may have some difficulty installing the free source code.
  388. Steve Davis (strat@cis.ksu.edu) has volunteered to maintain an archive of
  389. pre-built executable versions of the free JPEG code for various machines.
  390. His FTP archive is at ftp.cis.ksu.edu (129.130.10.80); look under /pub/JPEG
  391. to see what he currently has.  (The administrators of this system ask that
  392. FTP traffic be limited to non-prime hours.)  This archive is not maintained
  393. by the Independent JPEG Group, and files in it may not represent the latest
  394. free source code.
  395.  
  396. There are numerous commercial JPEG offerings, with more popping up every
  397. day.  I recommend that you not spend money on one of these unless you find
  398. the available free or shareware software vastly too slow.  In that case,
  399. purchase a hardware-assisted product.  Ask pointed questions about whether
  400. the product complies with the final JPEG standard and about whether it can
  401. handle the JFIF file format; many of the earliest commercial releases are
  402. not and never will be compatible with anyone else's files.
  403.  
  404.  
  405. 6B) If you are looking for source code to work with:
  406.  
  407. Free, portable C code for JPEG compression is available from the Independent
  408. JPEG Group, which I lead.  A package containing our source code,
  409. documentation, and some small test files is available from several places.
  410. The "official" archive site for this source code is ftp.uu.net (137.39.1.9
  411. or 192.48.96.9).  Look under directory /graphics/jpeg; the current release
  412. is jpegsrc.v3.tar.Z.  (This is a compressed TAR file; don't forget to
  413. retrieve in binary mode.)  You can retrieve this file by FTP or UUCP.
  414. Folks in Europe may find it easier to FTP from nic.funet.fi (see directory
  415. pub/graphics/programs/jpeg).  The source code is also available on
  416. CompuServe, in the GRAPHSUPPORT forum (GO PICS), library 10, as jpsrc3.zip.
  417. If you have no FTP access, you can retrieve the source from your nearest
  418. comp.sources.misc archive; version 3 appeared as issues 1-18 of volume 29.
  419. (See the "How to find sources" FAQ article, which appears regularly in
  420. news.answers, if you don't know how to retrieve comp.sources.misc postings.)
  421.  
  422. The free JPEG code provides conversion between JPEG "JFIF" format and image
  423. files in GIF, PBMPLUS PPM/PGM, Utah RLE, and Truevision Targa file formats.
  424. The core compression and decompression modules can easily be reused in other
  425. programs, such as image viewers.  The package is highly portable; we have
  426. tested it on many machines ranging from PCs to Crays.
  427.  
  428. We have released this software for both noncommercial and commercial use.
  429. Companies are welcome to use it as the basis for JPEG-related products.
  430. We do not ask a royalty, although we do ask for an acknowledgement in
  431. product literature (see the README file in the distribution for details).
  432. We hope to make this software industrial-quality --- although, as with
  433. anything that's free, we offer no warranty and accept no liability.
  434.  
  435. The Independent JPEG Group is a volunteer organization; if you'd like to
  436. contribute to improving our software, you are welcome to join.
  437.  
  438.  
  439. 7)  What's all this hoopla about color quantization?
  440.  
  441. Most people don't have full-color (24 bit per pixel) display hardware.
  442. Typical display hardware stores 8 or fewer bits per pixel, so it can display
  443. 256 or fewer distinct colors at a time.  To display a full-color image, the
  444. computer must map the image into an appropriate set of representative
  445. colors.  This process is called "color quantization".
  446.  
  447. Clearly, color quantization is a lossy process.  It turns out that for most
  448. images, the details of the color quantization algorithm have MUCH more impact
  449. on the final image quality than do any errors introduced by JPEG (except at
  450. the very lowest JPEG quality settings).
  451.  
  452. Since JPEG is inherently a full-color format, converting a JPEG image for
  453. display on 8-bit-or-less hardware requires color quantization.  On the other
  454. hand, a GIF image by definition has already been quantized to 256 or fewer
  455. colors.  For purposes of Usenet picture distribution, GIF has the advantage
  456. that the sender precomputes the color quantization, so recipients don't have
  457. to.  This is also the *disadvantage* of GIF: you're stuck with the sender's
  458. quantization.  If the sender quantized to a different number of colors than
  459. what you can display, you have to re-quantize, resulting in much poorer
  460. image quality than if you had quantized once from a full-color image.
  461. Furthermore, if the sender didn't use a high-quality color quantization
  462. algorithm, you're out of luck.
  463.  
  464. For this reason, JPEG offers the promise of significantly better image quality
  465. for all users whose machines don't match the sender's display hardware.
  466. JPEG's full color image can be quantized to precisely match the user's display
  467. hardware.  Furthermore, you will be able to take advantage of future
  468. improvements in quantization algorithms (there is a lot of active research in
  469. this area), or purchase better display hardware, to get a better view of JPEG
  470. images you already have.  With a GIF, you're stuck forevermore with what was
  471. sent.
  472.  
  473. It's also worth mentioning that many GIF-viewing programs include rather
  474. shoddy quantization routines.  If you view a 256-color GIF on a 16-color EGA
  475. display, for example, you are probably getting a much worse image than you
  476. need to.  This is partly an inevitable consequence of doing two color
  477. quantizations (one to create the GIF, one to display it), but often it's
  478. also due to sloppiness.  JPEG conversion programs will be forced to use
  479. high quality quantizers in order to get acceptable results at all, and in
  480. normal use they will quantize directly to the number of colors to be
  481. displayed.  Thus, JPEG is likely to provide better results than the average
  482. GIF program for low-color-resolution displays as well as high-resolution ones!
  483.  
  484.  
  485. 8)  How does JPEG work?
  486.  
  487. The buzz-words to know are chrominance subsampling, discrete cosine
  488. transforms, coefficient quantization, and Huffman or arithmetic entropy
  489. coding.  This article's long enough already, so I'm not going to say more
  490. than that.  For a good technical introduction, see:
  491.         Wallace, Gregory K.  "The JPEG Still Picture Compression Standard",
  492.         Communications of the ACM, April 1991 (vol. 34 no. 4), pp. 30-44.
  493. (Adjacent articles in that issue discuss MPEG motion picture compression,
  494. applications of JPEG, and related topics.)  If you don't have the CACM issue
  495. handy, a PostScript file containing a revised version of this article is
  496. available at ftp.uu.net, graphics/jpeg/wallace.ps.Z.  The file (actually a
  497. preprint for an article to appear in IEEE Trans. Consum. Elect.) omits the
  498. sample images that appeared in CACM, but it includes corrections and some
  499. added material.  Note: the Wallace article is copyright ACM and IEEE, and
  500. it may not be used for commercial purposes.
  501.  
  502.  
  503. 9)  What about lossless JPEG?
  504.  
  505. There's a great deal of confusion on this subject.  The JPEG committee did
  506. define a truly lossless compression algorithm, i.e., one that guarantees the
  507. final output is bit-for-bit identical to the original input.  However, this
  508. lossless mode has almost nothing in common with the regular, lossy JPEG
  509. algorithm.  At present, very few implementations of lossless JPEG exist,
  510. and all of them are commercial.
  511.  
  512. Saying "-Q 100" to the free JPEG software DOES NOT get you a lossless image.
  513. What it does get rid of is deliberate information loss in the coefficient
  514. quantization step.  There is still a good deal of information loss in the
  515. color subsampling step.  (There should be a command line switch to disable
  516. subsampling, but as of today, there isn't one.)
  517.  
  518. Even with both quantization and subsampling turned off, the regular JPEG
  519. algorithm is not lossless, because it is subject to roundoff errors in
  520. various calculations.  The maximum error is a few counts in any one pixel
  521. value; it's highly unlikely that this could be perceived by the human eye,
  522. but it might be a concern if you are doing machine processing of an image.
  523.  
  524. At this minimum-loss setting, regular JPEG produces files that are perhaps
  525. half the size of an uncompressed 24-bit-per-pixel image.  True lossless JPEG
  526. provides roughly the same amount of compression, but it guarantees
  527. bit-for-bit accuracy.
  528.  
  529. If you have an application requiring lossless storage of images with less
  530. than 6 bits per pixel (per color component), you may want to look into the
  531. JBIG bilevel image compression standard.  This performs better than JPEG
  532. lossless on such images.  JPEG lossless is superior to JBIG on images with
  533. 8 or more bits per pixel; furthermore, it is public domain, while the JBIG
  534. techniques are heavily covered by patents.
  535.  
  536.  
  537. 10)  Why all the argument about file formats?
  538.  
  539. Strictly speaking, JPEG refers only to a family of compression algorithms;
  540. it does *not* refer to a specific image file format.  The JPEG committee was
  541. prevented from defining a file format by turf wars within the international
  542. standards organizations.
  543.  
  544. Since we can't actually exchange images with anyone else unless we agree on
  545. a common file format, this leaves us with a problem.  In the absence of
  546. official standards, a number of JPEG program writers have just gone off to
  547. "do their own thing", and as a result their programs aren't compatible with
  548. anybody else's.
  549.  
  550. The closest thing we have to a de-facto standard JPEG format is some work
  551. that's been coordinated by people at C-Cube Microsystems.  They have defined
  552. two JPEG-based file formats:
  553.   * JFIF (JPEG File Interchange Format), a "low-end" format that transports
  554.     pixels and not much else.
  555.   * TIFF/JPEG, aka TIFF 6.0, an extension of the Aldus TIFF format.  TIFF is
  556.     a "high-end" format that will let you record just about everything you
  557.     ever wanted to know about an image, and a lot more besides :-).  TIFF is
  558.     a lot more complex than JFIF, and may well prove less transportable,
  559.     because different vendors have historically implemented slightly different
  560.     and incompatible subsets of TIFF.  It's not likely that adding JPEG to the
  561.     mix will do anything to improve this situation.
  562. Both of these formats were developed with input from all the major vendors
  563. of JPEG-related products; it's reasonably likely that future commercial
  564. products will adhere to one or both standards.
  565.  
  566. A particular case that people may be interested in is Apple's QuickTime
  567. software for the Macintosh.  QuickTime uses a JFIF-compatible format wrapped
  568. inside the Mac-specific PICT structure.  Conversion between JFIF and
  569. QuickTime JPEG is pretty straightforward; in fact Apple has released a
  570. utility program for the purpose (see PictPixie in section 6A).
  571.  
  572. I believe that Usenet should adopt JFIF as the replacement for GIF in
  573. picture postings.  JFIF is simpler than TIFF and is available now; the
  574. TIFF/JPEG spec is still not officially adopted.  Even when TIFF/JPEG is
  575. available, the JFIF format is likely to be a widely supported "lowest
  576. common denominator"; TIFF/JPEG files may never be as transportable.
  577.  
  578.  
  579. 11)  And what about arithmetic coding?
  580.  
  581. The JPEG spec defines two different "back end" modules for the final output
  582. of compressed data: either Huffman coding or arithmetic coding is allowed.
  583. The choice has no impact on image quality, but arithmetic coding usually
  584. produces a smaller compressed file.  On typical images, arithmetic coding
  585. produces a file 5 or 10 percent smaller than Huffman coding.  (All the
  586. file-size numbers previously cited are for Huffman coding.)
  587.  
  588. Unfortunately, the particular variant of arithmetic coding specified by the
  589. JPEG standard is subject to patents owned by IBM, AT&T, and Mitsubishi.
  590. Thus *you cannot legally use arithmetic coding* unless you obtain licenses
  591. from these companies.  (The "fair use" doctrine allows people to implement
  592. and test the algorithm, but actually storing any images with it is dubious
  593. at best.)
  594.  
  595. At least in the short run, I recommend that people not worry about
  596. arithmetic coding; the space savings isn't great enough to justify the
  597. potential legal hassles.  In particular, arithmetic coding *should not*
  598. be used for any images to be exchanged on Usenet.
  599.  
  600. There is some small chance that the legal situation may change in the
  601. future.  Stay tuned for further details.
  602.  
  603.  
  604. 12)  Does loss accumulate with repeated compression/decompression?
  605.  
  606. It would be nice if, having compressed an image with JPEG, you could
  607. decompress it, manipulate it (crop off a border, say), and recompress it
  608. without any further image degradation beyond what you lost initially.
  609. Unfortunately THIS IS NOT THE CASE.  In general, recompressing an altered
  610. image loses more information, though usually not as much as was lost the
  611. first time around.
  612.  
  613. The next best thing would be that if you decompress an image and recompress
  614. it *without changing it* then there is no further loss, i.e., you get an
  615. identical JPEG file.  Even this is not true; at least, not with the current
  616. free JPEG software.  It's essentially a problem of accumulation of roundoff
  617. error.  If you repeatedly compress and decompress, the image will eventually
  618. degrade to where you can see visible changes from the first-generation
  619. output.  (It usually takes many such cycles to get visible change.)
  620. One of the things on our to-do list is to see if accumulation of error can
  621. be avoided or limited, but I am not optimistic about it.
  622.  
  623. In any case, the most that could possibly be guaranteed would be that
  624. compressing the unmodified full-color output of djpeg, at the original
  625. quality setting, would introduce no further loss.  Even such simple changes
  626. as cropping off a border could cause further roundoff-error degradation.
  627. (If you're wondering why, it's because the pixel-block boundaries move.
  628. If you cropped off only multiples of 16 pixels, you might be safe, but
  629. that's a mighty limited capability!)
  630.  
  631. The bottom line is that JPEG is a useful format for archival storage and
  632. transmission of images, but you don't want to use it as an intermediate
  633. format for sequences of image manipulation steps.  Use a lossless format
  634. (PPM, RLE, TIFF, etc) while working on the image, then JPEG it when you are
  635. ready to file it away.  Aside from avoiding degradation, you will save a lot
  636. of compression/decompression time this way :-).
  637.  
  638.  
  639. ---------------------
  640.  
  641. For more information about JPEG in general or the free JPEG software in
  642. particular, contact the Independent JPEG Group at jpeg-info@uunet.uu.net.
  643.  
  644. --
  645.                         tom lane
  646.                         organizer, Independent JPEG Group
  647. Internet: tgl@cs.cmu.edu        BITNET: tgl%cs.cmu.edu@carnegie
  648.